System Nexus payload handling from WIT#1572
Conversation
tconley1428
force-pushed
the
nexusapigenintegration
branch
from
df8f660 to
cd4dd9b
Compare
tconley1428
changed the title
|
Guide on how to review this would be good |
|
@Sushisource reviewing in person with @THardy98 and @dplyukhin |
There was a problem hiding this comment.
just leaving it here that there was an idea to potentially add annotations on the wit types to identify to/from protos instead of having this model conversion helper file
| *positional_args: object, | ||
| args: list[typing.Any] | None = ..., |
There was a problem hiding this comment.
Why do some overloads take both positional_args and args if they're mutually exclusive?
There was a problem hiding this comment.
Why do we have this duplicate alongside the _generation_support/temporal_model_converters.py
There was a problem hiding this comment.
While in some sense not needed, this one is a nex-gen input, while the other is the output. I didn't want the tool to assume the support file provided would be present and accessible wherever the tool output was used. I wanted it to stand on its own. That said, we could change that.
4 participants
Summary
Adds WIT-generated Python bindings for Temporal system Nexus operations, starting with
WorkflowService.SignalWithStartWorkflowExecution, and exposes it asworkflow.signal_with_start_workflow.The generated call targets the server-reserved
__temporal_systemendpoint and uses the fully qualified service nametemporal.api.workflowservice.v1.WorkflowService.What changed
SignalWithStartWorkflowExecution.temporalio.workflowso newly generated operations are exposed without manual edits.Testing
Adds coverage for:
workflow.signal_with_start_workflowusing the system Nexus path